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“Knowledge  workers"  are  personnel  who  perform  busi¬ 
ness  processes  that  involve  the  use  of  information  re¬ 
sources  to  generate  a  product  that  is  itself  some  form  of 
manipulated  information.  The  U.S.  Army  Corps  of  Engi¬ 
neers’  Construction  Engineering  Research  Laboratories 
(USACERL)  is  conducting  research  and  development  on 
a  performance  support  environment  for  knowledge  work¬ 
ers  called  the  Knowledge  Worker  System  (KWS)  that 
enables  workgroups  to  define  the  tasks,  information 
resources,  institutional  knowledge,  and  computer  applica¬ 
tions  required  to  perform  their  business  processes.  KWS 
provides  the  capability  for  knowledge  workers  to  define 
associations  (“attachments’^  between  a  task  and  the 
information  resources  required  to  execute  their  tasks. 
Attachments  allow  knowledge  workers  to  access  docu¬ 
ments  while  executing  a  task,  and  can  be  associated  with 
any  electronically  stored  information  resource  from  any¬ 
where  within  the  KWS  process  model. 

This  research;  (1)  developed  a  strategy  for  providing 
KWS  users  with  improved  attachment  management  capa¬ 
bilities  and  (2)  developed  methods  to  implement  this 
strategy  through  a  series  of  modifications  to  KWS  Version 
2.0,  now  available  to  KWS  users. 
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1  Introduction 


Background 

In  both  the  government  and  industry,  a  large  number  of  personnel  are  classified  as 
“knowledge  workers.”  Knowledge  workers  perform  business  processes  that  involve  the 
use  of  information  resources  to  generate  a  product  that  is  not  necessarily  a  tangible 
item  such  as  a  piece  of  machinery,  but  is  itself  some  form  of  manipulated  information. 
For  example,  to  develop  a  government  contract  document,  a  knowledge  worker 
requires  access  to  a  variety  of  information  resources,  including  government  contracting 
regulations,  required  forms,  vendor  information,  previous  contracts,  information  on 
funds  status,  and  so  on.  The  knowledge  worker  uses  this  collected  information  to 
generate  the  final  product — ^the  contract  document. 

Because  information  is  the  primary  input  to  knowledge  work,  the  quality  of  a 
knowledge  worker’s  product  depends  on  the  ability  to  access  and  use  the  relevant 
documents  containing  this  information.  Managing  and  ensuring  access  to  documents 
has  always  been  a  difficult  task.  The  “Information  Age”  has  simplified  document 
creation  and,  as  a  result,  the  sheer  number  of  documents  has  increased  considerably. 
Because  of  this,  managing  documents — especially  in  electronic  form — ^has  become 
increasingly  difficult. 

The  U.S.  Army  Construction  Engineering  Research  Laboratories  (USACERL)  is 
conducting  research  and  development  on  a  performance  support  environment  for 
knowledge  workers  called  the  Knowledge  Worker  System  (KWS),  which  enables  a 
workgroup  to  define  the  tasks,  information  resources,  institutional  knowledge,  and 
computer  applications  required  to  perform  their  business  processes.  This  information 
is  stored  in  KWS,  making  it  available  to  support  task  execution. 

KWS  provides  online  access  to  information  resources  by  associating  specific  business 
processes  or  tasks  with  the  information  and/or  documents  required  to  support  those 
tasks.  For  example,  the  task  “Write  Technical  Report”  requires  the  use  of  several 
information  resources  as  well  as  the  actual  report  document  being  generated.  These 
resources  might  include  instructions  for  required  report  format,  content  guidelines, 
referenced  docximents,  author  notes,  and  a  word-processing  template  for  technical 
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reports.  Access  to  these  resources  is  then  provided  to  all  knowledge  workers  involved 
in  executing  the  defined  task. 

KWS  associations  can  be  made  to  any  electronically  stored  information  resoimce. 
These  associations  are  implemented  in  KWS  through  “attachment  links.”  The 
associated  electronic  documents  are  referred  to  as  “attachments.”  Users  can  access  the 
attachments  relevant  to  a  specific  task  from  anywhere  in  a  KWS  process  model 
(Figure  1). 

Attachments  may  be  defined  during  the  initial  development  of  a  KWS  business  process 
model  or  on  an  ad  hoc  basis  as  required  by  the  user.  Attachments  can  exist  in  a 
variety  of  formats  and  can  be  generated  by  multiple  sources.  As  the  size  and 
complexity  of  the  KWS  model  increases,  the  number,  format,  and  sources  of 
attachments  also  increases,  making  it  essential  that  KWS  effectively  manage  the 
creation  and  use  of  attachments  to  ensure  that  the  knowledge  worker  can  easily  access 
needed  information.  This  step  in  ongoing  KWS  research  investigated  the  effective 
management  of  attachments  within  KWS  and  developed  and  implemented  a  strategy 
to  provide  state-of-the  art  capabilities  for  attachment  management  within  KWS. 
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Objectives 

The  objectives  of  this  research  were  to:  (1)  develop  a  strategy  to  provide  KWS  users 
with  improved  attachment  management  capabilities  and  (2)  develop  methods  to 
implement  this  strategy  through  a  series  of  modifications  to  KWS. 


Approach 

The  basic  docmnent  management  requirements  of  knowledge  workers  were  identified 
and  commercially  available  document  management  services  were  reviewed  to 
determine  state-of-the-art  document  management  capabilities.  These  results  were 
used  to  develop  a  three-step  strategy  for  improving  KWS  attachment  management: 

1.  Existing  KWS  docmnent  management  capabilities  were  evaluated  and  required 
capabilities  not  currently  supported  were  identified.  This  information  was  used 
to  develop  specifications  for  modifying  KWS  to  meet  the  basic  requirements  to 
provide  knowledge  workers  with  more  effective  ways  to  access  the  required 
information  to  do  their  jobs. 

2.  To  provide  users  with  additional  document  management  capabilities  in  a 
relatively  short  time  period,  a  method  for  integrating  KWS  with  external,  off-the- 
shelf  applications  was  identified  and  demonstrated. 

3.  Advanced  document  management  requirements  of  knowledge  workers  were 
identified  and  potential  mechanisms  for  including  these  capabilities  in  future 
versions  of  KWS  were  described. 


Mode  of  Technology  Transfer 

The  findings  of  this  research  will  be  incorporated  into  current  and  future  USACERL 
work  units  addressing  the  development  of  the  Knowledge  Worker  System.  The 
USACERL  point  of  contact  for  obtaining  KWS  information  or  software  is: 

Wayne  Schmidt 

U.S.  Army  Construction  Engineering  Research  Laboratories  (USACERL) 

PO  Box  9005 

Champaign,  IL  61826-9005 

tel.  217/352-6511,  X7221,  or  (outside  Illinois)  1-800-USACERL 
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2  Knowledge  Worker  Document  Management 
Requirements 

Document  Management 

“Dociunent  management”  is  a  term  that  refers  to  the  storage,  retrieval,  tracking,  and 
administration  of  documents  within  an  organization.  The  term  originated  with  the  use 
of  manual  file  cabinets  to  store  paper-based  documents  in  alphabetized  categories 
based  on  the  documents’  contents.  Since  the  widespread  use  of  computer  technologies, 
dociunent  management  now  also  applies  to  electronic  documents  and  paper-based 
documents  converted  to  electronic  form.  Electronic  documents  exist  in  a  variety  of 
formats  including  word-processing  files,  spreadsheets,  graphics,  video,  audio,  bit¬ 
mapped  images,  and  compound  documents  incorporating  multiple  formats.  Now, 
instead  of  manual  file  cabinets,  automated  tools  for  document  management  are 
required  to  provide  users  with  services  to  access  electronic  documents. 

The  Knowledge  Worker  System  provides  electronic  access  to  information  resomces 
through  associations  of  specific  business  processes  with  the  documents  required  to 
support  that  task.  As  the  size  and  complexity  of  the  KWS  business  process  model 
increase,  the  number  of  attached  documents  also  increases.  KWS  must  provide 
document  management  services  to  effectively  manage  attached  documents  to  ensme 
that  the  knowledge  worker  can  easily  access  and  use  the  needed  information  to 
support  KWS  processes. 


Basic  Knowledge  Worker  Document  Management  Requirements 

The  following  sections  describe  the  basic  document  access  requirements  of  knowledge 
workers  and  the  document  management  services  that  KWS  requires  to  provide  simple 
access  to  and  manipulation  of  documents.  The  services  required  include  support  for 
document  creation,  storage,  retrieval,  tracking,  and  administration  within  an 
organization.  By  providing  these  services,  KWS  can  effectively  provide  knowledge 
workers  with  the  information  required  to  support  their  processes.  (Additiontd  services 
to  provide  more  advanced  support  will  be  discussed  in  Chapter  6.) 
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Document  Creation  and  Editing  via  Commerciai  Appiications. 

Knowledge  workers  use  a  variety  of  commercial  applications  to  create  and  edit 
dociiments,  including  word-processing,  spreadsheet,  graphics,  and  electronic  forms 
software.  KWS  users  need  to  be  able  to  access  their  preferred  commercial  applications 
to  create  and  edit  documents  from  within  KWS.  Document  management  services  must 
be  provided  that  support  these  commercial  applications. 

Document  Storage  and  Retrievai. 

After  documents  are  created,  services  are  required  that  eliminate  the  burden  on 
knowledge  workers  to  determine  specific  locations  where  the  documents  should  be 
stored.  This  is  analogous  to  deciding,  in  a  traditional  office,  in  which  file  and  file 
cabinet  to  physically  store  a  paper  document.  It  should  not  be  the  responsibility  of  the 
knowledge  worker  to  do  this;  document  management  services  should  be  provided  that 
determine  this  location  based  on  specific  information  about  the  document,  e.g.,  the 
individual  creating  the  document,  the  content  of  the  document,  and  the  business 
process  it  supports. 

Knowledge  workers  should  also  not  be  required  to  know  the  cr3rptic  DOS  file  naming 
structures  (e.g.,  “SERVERN VOLUME:  DIRECTORYNFILENAME”)  to  retrieve 
documents.  Instead,  knowledge  workers  should  he  able  to  retrieve  documents  using 
meaningfril  names  that  describe  the  content  of  the  document. 

Enterprise  Document  Storage  Architecture 

A  storage  architecture  can  ensure  knowledge  workers  access  to  documents  from 
anywhere  in  a  given  organization.  One  or  more  knowledge  workers  may  need  to  share 
documents  at  one  storage  site  or  across  multiple  storage  sites.  A  properly  designed 
architecture  will  define  where  to  store  documents  and  will  ensure  quick  access  to 
them.  In  traditional  terminology,  this  architecture  would  define  which  “file  cabinet” 
a  document  should  be  stored  in.  In  computer-based  terminology,  this  “file  cabinet”  is 
a  “file  server,”  accessible  via  the  computer  network.  The  enterprise  document  storage 
architecture  would  define  the  locations  of  the  various  file  servers  in  an  organization. 
Using  this  architecture,  documents  would  be  stored  on  the  appropriate  file  server  that 
would  enable  access  to  them  by  anyone  requiring  it. 

Muitipie  Storage  Media 

Knowledge  workers  also  require  support  for  storing  documents  to  a  number  of  different 
storage  media.  Besides  file  servers  on  local  area  networks  (LANs),  documents  can  be 


10 


USACERLADP  95/38 


stored  to  hard  disks,  Bernoulli  disks,  floppy  disks,  CD-ROM,  jvikeboxes,  and  so  on. 
These  naedia  serve  different  purposes  for  document  storage.  For  example,  storing  to 
floppy  disks  allows  knowledge  workers  to  remove  a  document  from  the  network  to  edit 
it  on  a  laptop  computer  away  from  the  office.  Jukeboxes  are  a  cost  effective  solution 
for  archiving  files  while  still  maintaining  the  capability  to  access  them  in  a  reasonable 
time  period.  Storage  management  routines  may  vary  and  would  be  determined  based 
on  the  organization’s  specific  document  storage  reqviirements. 

Backup  and  Archival 

The  information  stored  in  KWS  attachments  is  a  vital  organizational  resource. 
Mechanisms  are  required  that  ensure  the  safety  of  this  information.  The  capability 
to  back  up  documents  to  appropriate  media  is  required  and  should  be  performed  on  a 
regular  basis. 

As  the  number  of  attachments  in  KWS  grows,  so  do  the  number  of  documents. 
Because  of  storage  limitations  on  any  individual  file  server,  management  strategies 
are  required  that  migrate  files  to  secondary  storage  media.  These  strategies  would  be 
based  on  criteria  such  as  period  of  time  since  last  use.  Since  archived  documents  may 
be  reqviired  at  a  later  time,  services  are  also  required  to  allow  knowledge  workers  to 
retrieve  them  on  an  “as  needed”  basis. 

Shared  Document  Access 

The  collaborative  nature  of  KWS  may  precipitate  the  use  of  a  single  document  by  more 
than  one  knowledge  worker.  Because  of  this,  mechanisms  are  needed  to  maintain  the 
docvunent’s  integrity.  For  instance,  unless  document  management  services  prevent 
modifications  to  the  same  document  at  the  same  time,  the  document  will  not 
accurately  reflect  the  changes  made  by  simultaneous  edits.  This  document  sharing 
capability  would  allow  only  one  knowledge  worker  to  edit  a  document  at  a  time  while 
still  allowing  other  knowledge  workers  to  read  the  document. 

Document  Import  From  Multiple  Sources 

Many  documents  used  by  knowledge  workers  are  generated  from  external  sources  and 
originate  in  either  paper  or  electronic  format.  KWS  requires  the  capability  to  import 
electronic  documents  in  a  variety  of  formats,  including  word-processing  files, 
spreadsheets,  graphics,  video,  audio,  bit-mapped  images,  and  compound  documents 
incorporating  multiple  formats.  To  provide  quick  access  to  paper  documents  within 
KWS,  some  mechanism  must  provide  an  interface  between  KWS  and  electronic 
scanning  technologies  capable  of  converting  paper  documents  to  electronic  form.  Once 
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converted,  the  knowledge  worker  may  wish  to  either  view  or  edit  the  file.  Viewing  the 
file  requires  an  interface  to  technologies  that  allow  the  knowledge  worker  to  display 
the  electronic  image  of  the  document  generated  during  the  conversion  process;  editing 
requires  an  interface  to  optical  character  recognition  (OCR)  technologies  capable  of 
converting  the  electronic  image  of  the  document  into  a  word-processing  file  format. 

Document  Viewing 

Knowledge  workers  need  the  capability  to  view  documents  in  multiple  formats  without 
having  to  launch  the  application  used  to  create  it.  For  example,  a  knowledge  worker 
might  need  to  access  a  Standing  Operating  Procedure  (SOP)  relevant  to  the  task  being 
performed  only  for  reference — ^not  to  edit  it.  Without  this  capability,  the  knowledge 
worker  would  be  limited  to  viewing  only  those  documents  created  in  application 
software  for  which  they  have  legal  copies.  This  would  unnecessarily  limit  enterprise¬ 
wide  access  to  documents  generated  across  organizations  in  multiple  formats. 

Document  Versioning 

Versioning  provides  the  capability  to  track  changes  made  to  the  working  version  of  a 
document.  Multiple  revisions  of  the  working  document  can  be  maintained  to  allow  one 
or  more  users  to  modify  the  original  document.  Once  the  revisions  are  reviewed  and 
approved,  the  revisions  can  be  reconciled  to  produce  a  single  final  document. 
Versioning  also  provides  the  capability  to  track  multiple  versions  of  the  final  document 
generated  by  incremental  content  revisions.  For  example,  during  the  execution  of  a 
government  contract,  multiple  versions  of  the  contract  may  be  generated.  The  initial 
document  is  the  first  version  created  by  the  knowledge  worker.  Diuing  the  course  of 
contract  execution,  modifications  to  this  initial  document  may  be  required  to  add  to  or 
modify  the  contractor’s  tasks.  Throughout  the  process,  it  is  necessary  to  maintain  the 
initial  document  as  well  as  the  revised  document.  Versioning  provides  this  capability 
and  allows  tracking  the  history  of  the  contract. 

Security 

An  essentied  aspect  of  document  management  is  to  medntain  all  documents  secure  from 
unauthorized  access.  Each  document  varies  in  the  type  of  security  required  based  on 
its  content.  For  example,  there  are  legal  requirements  to  maintain  high  levels  of 
security  on  pre-award  contract  documents  until  the  contract  is  awarded.  After  that 
time,  the  document  must  be  made  available  to  anyone  requesting  it.  Some  documents 
may  require  different  levels  of  security.  For  example,  some  members  of  a  workgroup 
may  be  authorized  to  modify  a  document  while  others  may  only  be  allowed  to  view  it. 
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Document  management  services  must  also  provide  mechanisms  for  assigning  a  variety 
of  access  rights  to  each  document  based  on  its  information  content. 


Document  Management  Strategy  for  KWS 

Since  both  KWS  and  document  management  are  rapidly  developing  technologies,  an 
open-ended  approach  was  developed  to  incorporate  document  management  into  KWS. 
This  three-step  strategy  is  meant  to  provide  KWS  users  with  better  document 
management  capabilities  through  a  series  of  modifications  to  KWS  and  to  allow  access 
to  more  advanced  document  management  technologies  as  they  become  available. 

The  first  step  was  to  identify  the  immediate  document  management  capabilities 
required  to  support  basic  document  management  in  KWS  and  to  implement  them 
through  modification  of  KWS.  This  step  is  described  in  more  detail  in  the  following 
chapter. 

The  second  step  involved  identifying  a  mechanism  for  quickly  providing  state-of-the- 
art  document  management  capabilities  in  KWS  by  integrating  KWS  with  commercial 
DMSs.  The  feasibility  of  this  mechanism  was  demonstrated  through  a  prototype 
integration  with  a  single  commercial  DMS.  (This  step  is  described  in  more  detail  in 
Chapter  5.) 

The  third  step  was  to  define  advanced  document  management  capabilities  required  by 
knowledge  workers  and  to  provide  recommendations  for  providing  them  in  future 
versions  of  KWS.  These  recommendations  address  emerging  document  management 
technologies  and  are  described  in  Chapter  6. 
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3  Review  of  Document  Management  Systems 


Some  commercially  available  document  management  systems  (DMSs)  can  already 
provide  users  with  state-of-the-art  capabilities  for  document  management.  Attach¬ 
ment  management  in  KWS  adds  a  layer  of  complexity  to  managing  an  organization’s 
documents  due  to  the  need  to  maintain  the  task/document  associations.  However, 
many  of  the  capabilities  available  in  commercial  DMSs  can  be  directly  applied  to  KWS. 
A  review  of  commercially  available  DMSs  was  conducted  to  identify  the  capabilities 
they  support.  No  attempt  was  made  to  compare  the  capabilities  or  strengths  of 
individual  systems.  Rather,  this  review  concentrated  on  the  overall  capabilities  and 
the  benefits  such  systems  provide  to  users.  This  review  will  serve  as  input  into 
determining  how  document  management  can  be  improved  in  KWS. 

DMSs  automate  document  management  on  computer  networks.  (Standalone  DMSs 
do  exist  for  use  on  individual  workstations  but  were  not  considered  because  they  do  not 
support  file  sharing  throughout  an  organization.)  These  systems  make  it  possible  for 
workgroups  to  locate  and  share  documents  without  having  to  know  the  DOS  filename 
or  physical  location  of  the  document.  A  DMS  can  also  provide  system  administration 
functions  by  establishing  criteria  used  to  determine  storage  location  or  document 
archival  actions.  In  addition,  security  criteria  can  be  assigned  to  limit  unauthorized 
access  to  documents.  Essentially,  DMSs  provide  a  means  of  organized  access  and 
effective  administration  of  an  organization’s  documents. 

A  DMS  works  by  storing  critical  information  required  to  access  the  document  in  a 
document  “profile.”  The  profile  includes  such  information  as  the  document  type, 
author,  creation  date,  access  rights,  and  so  on.  A  good  DMS  allows  for  ctistomizing  the 
document  profile  to  meet  the  particular  needs  of  an  individual  organization.  This 
profile  information  is  stored  in  a  data  base  used  to  retrieve  the  document  without 
specifying  the  DOS  filename  and  storage  location.  Through  profiling,  a  DMS  provides 
quick  access  to  the  user’s  documents  by  allowing  the  use  of  meaningful  document 
names  and  searches  by  multiple  criteria  defined  in  the  profile.  Informative  file 
descriptions  can  be  specified  in  the  document  profile,  thus  eliminating  the  user’s  need 
to  know  the  cryptic  “SERVER\VOLUME:DIRECTORY\FILENAME”  DOS  file-naming 
structure.  For  example,  the  user  can  retrieve  a  file  by  specifying  a  descriptive  title 
such  as  “Knowledge  Worker  Document  Management  Strategy”  instead  of  (the  less 
intuitive)  “S:\  ATTACH\KAPPES\WPFILES\STRATRPT.WP6.” 
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In  addition  to  locating  docviments  from  the  information  stored  in  the  document  profile, 
a  DMS  can  also  index  document  text  allowing  users  to  perform  full  text  searches  to 
find  documents.  The  user  simply  needs  to  input  a  word  or  phrase  for  the  DMS  to  find 
and  list  all  of  the  documents  containing  that  input.  However,  the  additional  time  and 
overhead  required  for  generating  and  storing  the  indexes  for  this  capability  must  be 
considered  before  providing  it  to  users. 

Most  organizations  deal  with  documents  in  multiple  formats,  ranging  from  ASCII  text 
documents  to  spreadsheet  or  graphical  documents.  A  DMS  provides  support  to  allow 
users  to  either  edit  documents  in  any  format  or  to  view  and  print  them  without  having 
to  load  the  application  software  that  created  them.  A  DMS  can  also  provide 
mechanisms  for  converting  paper  documents  to  electronic  form  via  integration  with 
scanning  and  OCR  technologies. 

Other  features  provided  by  a  DMS  include  the  ability  to  copy  a  document  and  save  it 
with  a  new  profile,  to  generate  multiple  versions  of  a  single  document,  and  to  track 
changes  made  to  a  document.  A  DMS  can  also  provide  the  capability  to  temporarily 
check  out  documents  from  the  network.  The  “check  out”  procedure  copies  the 
document  to  a  removable  media  and  locks  access  to  the  original  document  on  the 
network  so  the  document  can  be  edited  at  another  location  such  as  a  laptop  computer 
away  from  the  office  and  then  checked  back  into  the  DMS.  If  another  user  tries  to 
access  a  checked  out  document,  the  DMS  will  indicate  that  it  has  been  checked  out, 
who  checked  it  out,  the  expected  return  date,  and  any  other  relevant  information. 

As  workgroups  produce  more  information,  the  storage  requirements  for  documents 
increase.  A  DMS  provides  administrative  capabilities  to  manage  these  increasing 
storage  requirements.  As  the  number  of  files  grows,  an  organization  will  not  be  able 
to  store  them  on  one  file  server.  It  is  therefore  important  to  develop  management 
strategies  for  migrating  files  to  secondary  storage  media.  These  strategies  can  be 
implemented  via  the  DMS  to  determine  where  a  document  is  stored,  how  long  it  is 
stored,  and  when  it  should  be  archived  to  another  location.  For  example,  a  document 
nan  be  tagged  for  archival  based  on  the  period  of  time  since  its  last  use.  An  important 
feature  is  that,  even  though  the  document  is  moved  ofF-line,  the  profile  information  is 
retained  so  users  can  still  retrieve  the  document  when  necessary. 

A  DMS  can  also  support  enterprise-wide  access  to  documents  by  allowing  document 
sharing  across  multiple  servers  on  the  LAN  or  on  servers  at  remote  locations.  This 
capability  allows  large  organizations  spread  across  various  physical  locations  to  deal 
with  documents  residing  at  multiple  locations  as  a  single  corporate  information 


resource. 
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Although  DMSs  support  many  capabilities,  it  was  also  found  that  they  are  an  evolving 
technology.  Because  of  this,  considerable  effort  is  required  to  install  and  update  a 
DMS  and  incompatibilities  exist  between  the  various  systems.  Standards  are  being 
developed  to  address  these  issues  and  should  soon  be  available.  In  addition*  the 
evolving  nature  of  this  technology  is  an  indication  that  more  capabilities  will  be 
provided  as  the  technology  matures. 
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4  Basic  Document  Management  in  KWS 


introduction 

The  requirement  for  effective  document  management  is  not  unique  to  KWS.  However, 
KWS  is  unique  in  the  way  that  it  provides  direct  associations  between  the  document 
and  the  task  being  performed.  Therefore,  document  management  within  KWS  also 
refers  to  the  maintenance  of  the  associations  between  a  task  and  a  document  as 
defined  in  the  attachment  link.  Because  of  this  additional  requirement,  document 
management  within  KWS  is  also  referred  to  as  “attachment  management.” 


Review  of  KWS  Version  1.7  Attachment  Management 

The  basic  requirements  for  attachment  management  in  KWS  include  those  described 
in  Chapter  2  for  simple  access  and  manipulation  of  attachments  within  a  workgroup. 
In  addition,  there  is  a  requirement  for  attachment  maintenance  to  manage  the  task/ 
document  associations.  KWS  Version  1.7  was  reviewed  to  identify  the  attachment 
management  fiinctions  already  provided  and  to  determine  if  it  provided  the 
capabilities  required.  After  this  review,  the  modifications  to  KWS  required  to  improve 
attachment  management  were  developed  and  implemented  in  KWS  Version  2.0. 


Attachment  Creation 

Within  KWS  Version  1.7,  attachment  links  can  only  be  made  to  documents  previously 
created  outside  of  the  KWS  environment.  For  example,  if  a  KWS  user  is  performing 
a  task  that  requires  the  creation  and  editing  of  a  word-processing  document,  the  user 
must  open  the  word-processing  application,  create  the  file,  edit  it,  and  save  it  to  a  user¬ 
generated  filename.  The  user  must  then  create  an  attachment  link  within  KWS  to 
that  attachment  document.  Since  KWS  does  not  support  the  capability  to  automati¬ 
cally  create  and  link  attachment  documents  within  KWS,  the  user  must  execute  the 
steps  required  to  ensure  the  attachment  link  is  made.  In  many  cases,  the  user  may 
forget  to  link  the  attachment  or  avoid  the  extra  work  and  use  the  document  entirely 
outside  the  KWS  environment.  As  a  result,  important  task/information  associations 
supporting  the  tasks  performed  by  the  individual  are  not  captured  as  part  of  the 
business  process,  already  reducing  the  benefits  normally  gained  by  KWS. 


USACERL  ADP  95/38 


17 


Attachment  Modification 

Attachments  are  modified  through  the  “attachment  modify”  option  in  KWS.  The 
software  application  used  to  launch  the  attachment  is  defined  when  the  attachment 
link  is  made  hy  specifying  the  DOS  command  line  required  to  execute  the  application. 
KWS  uses  this  definition  to  launch  the  specified  application  with  the  associated 
filename.  One  problem  with  this  is  that  the  command  line  is  specific  to  the  individual 
user  creating  the  attachment  link.  For  example,  if  an  attachment  link  is  defined  for 
a  document  created  in  WordPerfect,  the  user  must  specify  the  command  line  used  to 
execute  WordPerfect  on  the  individual  workstation,  e.g.,  “C:\WPWIN\  WPWIN.EXE.” 
This  command  may  work  for  some  users,  hut  it  will  not  work  for  those  vidth  Word¬ 
Perfect  installed  in  a  different  drive  or  directory. 

File  Storage  Management 

Attachment  links  in  KWS  are  generated  by  the  user  who  must  specify  where  the 
document  is  located  when  creating  a  link.  Once  the  link  is  made,  the  attachment 
remains  in  the  location  specified.  This  approach  can  result  in  attachment  files  being 
stored  in  various  locations  throughout  the  organization.  Lack  of  storage  management 
routines  can  result  in:  (1)  users  being  unable  to  share  documents,  (2)  administrators 
being  unable  to  back  up  and  archive  KWS  attachments,  and  (3)  accidental  corruption 
of  the  attachment  link. 

The  ability  to  effectively  share  dociiments  in  a  workgroup  depends  on  the  users’ 
abilities  to  access  attachments.  If  an  attachment  is  stored  to  a  local  hard  drive  instead 
of  a  shared  file  server,  no  one  can  access  it  except  from  that  workstation.  Guidance  on 
efficient  directory  structures  for  storing  KWS  attachments  can  be  given  to  users  to 
decrease  this  problem,  but  automated  management  routines  are  reqmred  to  enforce 
them.  These  automated  routines  could  determine  where  files  are  stored  based  on 
whether  the  document  is  to  be  accessed  by  other  members  of  the  workgroup  or  by  only 
one  individual. 

When  documents  are  spread  out  in  various  locations  with  no  discemable  directory 
structure,  maintenance  functions  for  backing  up  and  archiving  files  are  unnecessarily 
complex  if  not  impossible.  Storage  management  routines  should  enforce  storage  of 
attachments  to  centralized  storage  locations  dedicated  completely  to  KWS  attach¬ 
ments.  This  will  simplify  maintenance  functions  for  backing  up  files  since  the  system 
administrator  will  know  the  exact  locations  that  contain  KWS  attachment  documents. 

Attachment  links  to  documents  stored  in  random  locations  are  very  vulnerable  to 
accidental  corruption,  which  may  occur  when  the  attached  file  is  either  deleted, 
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renamed,  or  moved  using  DOS  file  commands  from  outside  of  the  KWS  environment. 
If  the  user  tries  to  access  an  attachment  with  a  corrupted  link,  KWS  will  be  unable  to 
find  it  since  the  original  filename  has  been  changed.  Centralized  storage  management 
routines  within  KWS  can  prohibit  or  at  least  limit  file  access  via  external  DOS  file 
commands,  thereby  avoiding  accidental  corruption.  If  corruption  does  occur,  recovery 
could  then  be  possible  through  backup  mechanisms. 

Security  Features 

No  mechanism  is  provided  for  limiting  unauthorized  access  to  attachments  within 
KWS  Version  1.7.  Without  these  security  features,  attachments  are  not  protected  from 
modification  by  unauthorized  users.  This  weakness  forces  users  who  want  limited 
attachment  access  to  store  documents  on  a  local  workstation  or  to  floppy  disks  that  can 
be  sheired  only  by  selected  individuals,  a  method  unacceptable  in  a  workgroup 
environment.  A  capability  to  store  attachments  on  a  shared  file  server  and  to 
designate  specific  access  rights  to  selected  members  of  the  workgroup  is  a  better 
solution.  Access  rights  assignment  in  KWS  would  limit  access  to  attachments,  thereby 
assuring  users  that  their  attached  documents  are  secure  from  unauthorized  access. 
For  example,  certain  individuals  may  need  access  to  edit  a  document  while  others  may 
only  need  to  look  at  it.  In  some  cases,  KWS  need  only  indicate  that  there  is  an 
attachment  and  provide  no  access  rights  to  it  at  all.  If  an  attachment  were  stored  on 
a  user’s  local  workstation,  and  the  user  tried  to  access  it  fi*om  another  workstation, 
KWS’  attempt  to  retrieve  the  document  would  fail.  Instead  of  attempting  to  access  the 
document,  KWS  wovild  indicate  to  the  user  that  they  do  not  have  access  rights  to  the 
document.  To  gain  access  to  the  document,  the  user  could  then  request  authorization 
from  the  attachment’s  owner. 

Attachment  Viewing 

Document  viewing  allows  users  to  view  documents  without  having  to  launch  the 
application  used  to  create  it.  KWS  Version  1.7  allows  for  viewing  text  files  only  so  that 
users  must  have  a  copy  of  certain  applications  used  to  create  attachment  documents 
before  they  can  view  them.  Even  if  a  user  has  the  application,  it  is  important  to  note 
that  it  may  be  improper  to  allow  a  user  to  view  an  attachment  by  laimching  an 
application  since  the  objective  is  to  “view  only,”  not  to  retrieve  or  edit  the  file. 
Allowing  the  application  launch  subjects  the  attachment  to  unauthorized  modifica¬ 
tions. 
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Attachment  Tracking 

KWS  Version  1.7  does  not  provide  any  features  for  tracking  the  history  of  attachment 
documents.  It  is  important  to  keep  a  history  of  when  the  attachment  was  created)  who 
created  it,  who  edited  it  last,  and  when  it  was  last  changed.  This  information  can  be 
used  for  several  purposes.  First,  it  provides  the  user  with  a  quick  overview  of  who  is 
responsible  for  the  document  and  how  current  it  is.  Next,  KWS  can  use  this 
information  to  facilitate  security  and  archival  mechanisms.  For  example,  KWS  could 
enable  document  archival  based  on  the  period  of  time  since  the  last  edit.  In  addition, 
access  rights  to  attachment  links  could  be  restricted  to  the  attachment  creator 
providing  security  against  unauthorized  modifications. 

Attachment  Versioning 

Versioning  provides  the  capability  to  save  variations  of  a  single  document  as  separate 
files  that  can  be  used  to  track  revisions  to  a  document.  KWS  can  provide  this  function, 
but  not  in  an  efficient  manner.  The  user  must  select  a  “Get  Cop3r”  option  in  KWS, 
which  copies  the  document  to  a  user-specified  location.  The  user  is  then  responsible 
for  creating  an  attachment  link  to  the  new  document  and  specifying  in  the  Attachment 
Title  that  it  is  a  version  of  the  original  document.  This  time-consuming  method 
precludes  the  possibility  for  KWS  to  provide  mechanisms  for  ensuring  that  the 
versions  are  maintained  as  a  single  entity  for  other  document  management  functions, 
i.e.,  archival. 

Tracking  Attachment  Links 

KWS  allows  a  single  document  to  be  attached  to  multiple  tasks  causing  a  unique 
management  requirement.  The  number  of  links  associated  with  an  attachment  file  are 
maintained  by  KWS,  but  are  not  displayed  to  the  user.  This  information  could  be 
useful  in  understanding  the  impact  of  the  process  on  the  attachment  document.  For 
example,  if  the  attachment  were  linked  to  a  series  of  tasks  in  a  review  process,  the 
user  woidd  be  able  to  easily  view  the  actions  that  will  be  performed  on  the  attachment. 
KWS  should  also  use  this  information  for  determining  if  documents  should  be  deleted 
after  all  attachment  links  have  been  removed.  This  could  lead  to  a  large  number  of 
useless  attachment  documents  being  stored  on  the  user’s  local  workstation  or  shared 
file  server.  Although  this  deletion  should  not  be  automatic;  the  user  has  the  option  to 
move  the  document  to  another  location  when  all  links  are  removed. 
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Automatic  Document  Attachment 

Dociiments  can  be  created  within  KWS  as  the  result  of  executing  external  software 
applications.  For  example,  a  report  can  be  generated  by  a  query  to  a  mainframe  data 
base  system  or  a  document  generated  from  an  electronic  forms  package.  KWS  provides 
this  capability  through  the  “Do  It”  function.  For  instance,  the  task  “Generate  Funding 
Authorization  Report”  could  have  a  “Do  It”  linked  to  it  that  executes  a  computer 
application  for  logging  onto  a  mainframe  data  base,  generating  the  report,  and  storing 
the  report  to  the  user’s  workstation.  On  completion  of  this  “Do  It,”  KWS  should 
automatically  attach  the  generated  report  to  the  task.  KWS  Version  1.7  does  not 
support  automatic  document  attachment. 

Exporting  Attachments 

On  occasion,  a  knowledge  worker  may  require  access  to  a  copy  of  an  attachment 
outside  of  the  KWS  environment.  KWS  does  provide  users  this  capability  through  the 
Get  Copy  option.  This  option  will  save  a  copy  of  an  attachment  file  to  a  KWS  user- 
specified  location  and  filename.  For  example,  a  user  might  need  this  option  to  convert 
an  attachment  file  into  another  application  or  file  format,  e.g.,  to  convert  a  PowerPoint 
attachment  file  to  a  Freelance  format.  The  user  would  not  be  able  to  do  this  by  making 
another  version  of  the  attachment  and  changing  the  Application  value  since  Freelance 
would  require  the  user  to  convert  the  attachment  to  its  format  via  the  Freelance 
Import  option.  However,  the  user  could  use  Get  Copy  to  save  the  file  to  their  hard 
disk,  import  it  into  Freelance,  save  the  file  and  then  import  it  back  into  KWS. 

Get  Copy  provides  a  valuable  function  to  KWS  users;  however  it  could  lead  to  problems 
if  the  user’s  intent  was  similar  to  the  “check  out”  capability  described  in  Chapter  2. 
Once  the  user  removes  the  document  from  the  KWS  environment,  the  only  way  to 
return  it  is  to  create  another  attachment  link  to  it.  However,  if  the  document  were 
edited  outside  of  KWS  and  returned  via  a  new  link,  there  could  be  confusion  as  to  what 
to  do  with  the  original  file.  Should  it  be  removed,  or  should  it  be  considered  a  version? 
Also,  if  the  original  attachment  in  KWS  were  not  protected  from  update  while  the  copy 
was  out  of  KWS,  there  is  no  way  to  indicate  if  changes  were  made. 


KWS  Attachment  Management  Modifications 

After  reviewing  the  existing  capabilities  for  attachment  management  in  KWS  Version 
1.7  and  those  reqviired  by  knowledge  workers,  a  set  of  modifications  to  KWS  that  could 
be  implemented  in  a  short  time  period  were  defined.  These  modifications  were  then 
implemented  in  KWS  Version  2.0. 
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KWS’s  capacity  to  support  attachment  management  was  expanded  by  adding 
Attachment  Profiling,  storage  management  routines,  and  new  options  for  creating, 
editing,  viewing,  and  versioning  attachments.  Essentially,  these  features  resulted  in 
the  modification  of  the  KWS  data  base  to  support  the  additional  attributes  required 
in  the  attachment  profile  and  modification  of  the  KWS  software  to  support  the  added 
functionalities. 

Storage  Management  Routines 

When  attachments  are  created  within  KWS,  the  attachment  is  now  given  a  KWS- 
generated  document  name  and  stored  in  a  location  reserved  specifically  for  KWS 
attachment  documents.  This  location  is  based  on  the  Storage  Type  assigned  to  the 
attachment  by  the  user  (described  in  more  detail  later  in  this  chapter).  The  user  is 
only  required  to  designate  this  value  and  is  not  responsible  for  determining  the  actual 
physical  location  where  the  docmnent  is  to  be  stored.  KWS  then  uses  the  Storage  Type 
value  and  information  specific  to  the  user’s  organization  to  determine  the  physical 
location  to  store  the  document. 

Automated  management  routines  for  attachment  backup  were  not  included  in  this 
modification.  However,  this  process  has  been  simplified  by  the  centralized  storage 
mechanisms  enforced  by  KWS.  Routine  network  and  workstation  backups  can  now  be 
performed  on  storage  locations  established  for  the  organization  during  KWS 
installation.  Archival  routines  were  also  not  included,  but  will  be  addressed  in  future 
modifications. 

Viewing  Attachments 

The  capability  to  display  a  selected  attachment  without  launching  the  associated 
application  has  been  added  to  KWS  through  an  external  interface  between  KWS  and 
commercially  available  file  viewing  software.  A  file  viewer  is  a  software  package  that 
displays  the  contents  of  a  file  as  it  would  normally  be  displayed  in  the  application  that 
created  it.  A  variety  of  commercially  available  file  viewers  will  sdlow  \isers  to  view 
common  file  formats  such  as  text  files,  word-processing  documents,  data  base  files,  and 
graphic  files.  For  instance,  a  file  created  in  WordPerfect  can  be  viewed  on  the 
computer  screen  without  requiring  a  copy  of  WordPerfect.  KWS  will  not  require  a  user 
to  have  a  file  viewing  package,  and  if  the  user  does  not  specify  a  file  viewer,  the  View 
option  will  not  be  available. 
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The  Attachment  Profile 

KWS  was  modified  to  include  the  capability  to  “profile”  attachments.  The  Attachment 
Profile  is  used  in  KWS  to  describe  each  attachment  linked  to  a  task  (Figure  2).  When 
an  attachment  is  created  within  KWS,  the  profile  information  is  stored  in  the  KWS 
data  bsise  and  is  used  to  search  for  and  retrieve  the  file.  The  attributes  associated  with 
an  attachment  that  were  considered  essential  to  meet  KWS’s  basic  attachment 
management  requirements  were; 

•  Attachment  Title 

•  Application 

•  Storage  Type 

•  Access  Rights 

•  Version 

•  Attached  By 

•  Date  Attached 

•  Last  Edit  By 

•  Last  Edit  Date 

•  Link. 

Attachment  Title.  The  Attachment  Title  is  a  descriptive  name  given  to  the  attachment 
document  that  is  not  the  actual  DOS  filename.  For  an  individual  task,  the  Attachment 
Title  should  be  unique.  However,  the  Attachment  Title  does  not  have  to  be  xmique 
across  all  tasks  since  the  combination  of  the  task/attachment  title  will  provide 
uniqueness. 
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Application.  Application  identifies  the  computer  program  used  to  create  and  launch 
the  attachment  file.  The  user  selects  the  Application  value  from  a  list  of  available 
applications.  This  list  is  generated  when  KWS  is  initially  installed  on  the  user’s 
workstation.  The  list  conUdns  information  about  the  name  of  the  application  and  the 
command  line  used  to  execute  the  software.  It  can  be  easily  modified  by  the  user  as 
software  packages  are  removed  or  added  to  the  user’s  environment.  This  modification 
allows  a  user  to  define  the  command  line  that  executes  the  application  separately  from 
the  attachment’s  profile.  This  eliminates  the  problem  that  occurs  where  one  user  is 
unable  to  access  an  attachment  because  of  an  incompatibility  in  the  command  line. 

When  attaching  an  existing  document,  KWS  will  try  to  identify  the  associated 
application  from  the  filename  extension  euid  display  it  as  the  Application  value; 
otherwise,  the  value  is  left  blank  and  the  user  must  select  it  from  the  application  list. 
If  the  application  is  not  on  the  list,  the  user  must  add  it  to  the  application  list  and  then 
set  the  value.  The  Attachment  Profile  can  be  saved  with  the  Application  value  as 
blank,  but  the  user  will  not  be  able  to  modify  the  attachment  since  KWS  will  be  imable 
to  lavmch  the  associated  application.  However,  even  if  the  Application  value  is  blank, 
the  user  is  still  able  to  view  the  attachment  document  since  the  originating  application 
is  no  longer  necessary  for  viewing. 

The  Application  value  also  provides  KWS  user’s  with  the  capability  to  create  a 
document  within  KWS  and  have  it  automatically  linked  as  an  attachment.  To  do  this, 
the  user  completes  the  Attachment  Profile  for  the  attachment  to  be  created.  The 
application  is  then  launched  using  the  defined  application  command  line  retrieved 
from  the  Application  List  and  the  KWS-generated  filename.  The  user  then  follows 
normal  procedures  for  creating  and  saving  the  document  within  the  selected 
application. 

Storage  Type.  The  Storage  Type  value  is  used  to  indicate  the  storage  location  type  of 
the  attachment.  The  available  values  for  Storage  Type  are  “Public,”  “Private,”  or 
“Removable.”  Attachments  with  Storage  Type  Public  are  stored  on  the  KWS  shared 
file  server  on  the  LAN,  storage  type  Private  are  stored  in  the  \KWS  \ATTACH 
directory  on  the  user’s  KWS  workstation,  and  Removable  are  stored  on  user- 
designated  removable  media  such  as  floppy  or  Bernoulli  disks.  The  directories  for 
Public  and  Private  attachments  are  defined  by  the  KWS  system  administrator  during 
the  KWS  installation  process.  When  an  attachment  file  is  designated  as  “Removable,” 
the  user  is  prompted  to:  (1)  specify  the  drive  and  directory  of  the  removable  media  for 
storing  the  file  and  (2)  enter  a  description  used  to  physically  identify  the  media.  KWS 
will  then  store  this  information  and  use  it  to  assist  the  user  in  subsequent  retrievals 
of  the  attachment.  For  example,  if  the  attachment  file  '"McClendon  MADOC  contract” 
is  stored  to  the  user’s  Bernoulli  disk  labeled  MADOC  contracts  #1  in  drive  d:,  KWS  will 
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display  a  message  to  the  user  requesting  that  they  '^Insert  Bernoulli  disk  titled 
MADOC  contracts  #1  in  drive  d:\”  to  retrieve  the  attachment  file  “McClendon  MADOC 
contract.” 

Access  Rights.  The  Access  Rights  value  indicates  who  has  authorization  to  access  the 
attachment.  Current  options  are  View  Profile,  Read/Copy,  and  Read/Copy/Edit.  View 
r*rofile  allows  users  to  view  the  attachment  profile,  but  not  to  access  the  attachment. 
Read/Copy  allows  users  to  view  the  attachment  profile  and  read  or  to  make  copies  of 
the  original  attachment.  Read/Copy/Edit  allows  xisers  full  rights  to  view,  copy,  or  edit 
the  attachment  as  well  as  to  view  the  Attachment  Profile. 

KWS  automatically  gives  the  attachment’s  creator  Read/Copy/Edit  access  rights  to  the 
attachment.  In  addition,  only  the  attachment  creator  is  allowed  to  edit  or  delete  an 
attachment  profile.  This  ensures  that  unauthorized  users  do  not  alter  an  attachment 
profile.  The  attachment  creator  can  change  the  defaults  as  desired  by  selecting  values 
from  the  available  options. 

KWS  provides  default  values  for  Access  Rights  to  other  users  based  on  the  value  of 
Storage  Type.  The  default  value  given  for  Public  attachments  is  Read/Copy  access 
rights  to  all  users.  The  default  value  for  Private  attachments  is  View  Profile  access 
rights  to  all  users.  Allowing  access  to  a  Private  attachment  would  result  in  a  retrieval 
failure  since  Private  attachments  are  stored  to  the  attachment  creator’s  local 
workstation.  Even  if  users  are  not  able  to  access  the  document,  by  giving  them  View 
Profile  access,  they  are  able  to  determine  who  owns  the  attachment  so  they  can  be 
contacted  if  access  is  desired. 

KWS  also  allows  users  to  designate  an  attachment  as  “Sensitive.”  By  doing  this,  KWS 
imposes  restrictions  to  allow  only  the  attachment  creator  to  view  the  attachment 
profile  and  access  the  attachment  file.  In  addition,  the  Storage  Type  value  is  forced 
to  Removable.  Forcing  sensitive  attachments  to  be  stored  on  a  removable  media 
ensures  that  users  do  not  inadvertently  mark  a  file  sensitive  while  keeping  the  Storage 
Type  value  Public,  or  make  the  storage  type  Private  while  causing  the  attachment  to 
be  stored  on  a  nonsecurable  media  such  as  their  local  workstation  or  shared  file  server. 
If  an  attachment  is  Sensitive,  KWS  does  not  display  the  attachment  link  to  unautho¬ 
rized  users.  This  provides  additional  seciuity  since,  if  other  users  do  not  know  that  the 
attachment  exists,  they  would  be  unlikely  to  try  to  obtain  access  by  other  methods. 
These  modifications  did  not  address  security  for  sensitive  attachments  stored  on 
nonremovable  media  since  these  functions  must  be  provided  via  network  security 
protocols  or  file  encryption  mechanisms  and  were  beyond  the  scope  of  basic  attachment 
management. 
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Version.  This  value  conteins  the  version  number  of  the  attachment  file.  KWS  provides 
the  capability  for  users  to  quickly  create  new  versions  of  a  document  through  the 
Version  option.  When  a  new  version  is  created,  a  copy  of  the  attachment  is  made,  the 
highest  version  number  of  the  selected  attachment  is  incremented  by  one  and  assigned 
to  the  new  version  of  the  attachment.  The  version  creator  will  then  be  the  owner  of  the 
new  version  which  will  be  reflected  in  the  “Attached  By”  field  value.  All  other  profile 
information  remains  the  same  and  the  user  is  no  longer  allowed  to  edit  the  “Attach¬ 
ment  Title.”  This  restriction  is  imposed  to  maintain  the  relationship  between  the 
original  document  and  its  revisions.  Allowing  a  name  change  would  essentially  change 
the  attachment  to  a  copy  of  the  original — not  a  revision.  Future  modifications  should 
include  management  capabilities  that  treat  an  attachment  and  its  versions  as  a  single 
entity.  For  example,  deleting  an.attachment  with  versions  should  remove  all  instances 
of  the  attachment.  The  current  versioning  structure  will  support  additional 
modifications  to  KWS  to  allow  for  more  sophisticated  management. 

Attached  By.  This  value  contains  the  KWS  ID  of  the  user  who  created  the  link  to  the 
attachment  file.  This  value  is  used  by  KWS  to  determine  who  has  subsequent  rights 
to  modify  the  attachment’s  profile.  Only  the  attachment  creator  or  System  Adminis¬ 
trator  will  be  able  to  modify  an  attachment  profile.  If  a  user  other  than  the  one  who 
created  the  link  establishes  another  link  to  the  attachment  file  from  another  task,  the 
original  creator  will  still  maintain  ownership  of  the  link  and  will  be  the  only  one  able 
to  modify  the  attachment’s  profile.  If  another  user  makes  a  copy  of  the  attachment  file 
and  links  it  to  another  task,  a  new  attachment  profile  is  created  and  the  KWS  ID  of 
the  user  copjdng  the  attachment  becomes  the  value  of  the  Attached  By  field. 

The  following  attributes  were  added  to  KWS  to  provide  simple  history  tracking 
mechanisms: 

Date  Attached.  This  is  the  date  the  attachment  was  created. 

Last  Edit  By.  Contains  the  KWS  ID  of  the  user  who  last  edited  the  attachment  file. 

Last  Edit  Date.  Contains  the  date  the  attachment  file  was  last  edited. 

Links.  This  value  contains  the  number  of  links  associated  with  an  attachment  file. 
From  within  the  Attachment  Profile,  a  KWS  user  can  display  a  list  of  the  titles  of  all 
tasks  currently  linked  to  the  attachment  file.  As  stated  previously,  this  information 
is  useful  for  understanding  the  impact  of  the  process  on  the  attachment  document. 
KWS  was  also  modified  to  use  the  link  value  for  determining  if  documents  should  be 
deleted  after  all  attachment  links  have  been  removed.  This  deletion  is  not  automatic. 
The  user  is  given  the  option  to  move  the  document  to  another  storage  location  when 
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all  links  are  removed  if  desired.  This  will  eliminate  the  problem  of  managing  non- 
KWS  documents  being  stored  in  KWS-only  designated  storage  location. 

Modifications  were  also  made  to  the  methods  used  by  EWS  Version  1.7  to  manipulate 
attachment  links.  Users  need  the  capability  to: 

1.  Link  multiple  attachments  to  a  single  task 

2.  Link  multiple  tasks  to  a  single  attachment 

3.  Make  a  copy  of  an  attachment  and  link  it  to  a  new  task 

4.  Move  a  link  between  an  attachment  and  a  task  to  another  task  (Figure  3). 

KWS  was  found  acceptable  in  its  capability  to  support  the  first  requirement,  but 
changes  were  required  to  improve  support  for  the  rest.  The  ability  of  users  to  perform 
these  fimctions  have  also  been  impacted  by  the  addition  of  the  Access  Rights  described 
previously.  Essentially,  the  attachment  creator  owns  the  link  between  the  attachment 
and  the  task.  The  effect  of  this  ownership  limits  other  users  from  deleting  or  moving 
links  they  do  not  own. 

Linking  multiple  tasks  to  a  single  attachment  was  provided  in  KWS  Version  1.7 
through  the  Copy  function.  However,  this  was  an  improper  implementation  since  it 
appeared  to  the  user  that  they  had  made  a  copy  of  the  attachment  that  could  be 
modified  without  affecting  the  original  attachment.  In  actuality,  the  user  had  created 
another  link  to  the  same  attachment  and  any  modifications  made  from  either  task 
were  made  to  that  same  attachment.  To  correct  this  problem,  the  Copy  function  was 
modified  to  allow  the  user  to  create  a  new  copy  of  the  attachment  file  and  link  it  with 
the  desired  task  (Requirement  3).  Any  relationship  with  the  previous  link  is  now 
removed.  All  profile  information  remains  the  same  as  the  original  attachment  file 
except  for  the  Attached  By  and  Date  Attached  values,  which  are  updated  by  KWS.  The 
user  can  then  change  profile  information  for  the  new  attachment  if  desired. 

The  function  of  linking  attachments  to  multiple  tasks  previously  provided  by  Copy  is 
now  performed  by  the  Link  option.  Link  creates  a  new  link  between  an  existing 
attachment  and  the  selected  task.  Any  modifications  performed  on  the  attachment  for 
any  of  the  linked  tasks  are  reflected  in  all  linked  instances  of  the  attachment.  All 
previous  links  and  profile  information  remain  the  same.  KWS  was  found  acceptable 
in  it’s  ability  to  move  attachment  links  to  other  tasks  (requirement  4).  Move  creates 
a  link  with  a  new  task  and  deletes  the  link  from  the  original  task.  The  new  Access 
Rights  allow  only  the  attachment  creator  to  move  a  task. 
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(d)  Attachment  link  moved  from 
one  task  to  another. 
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Figure  3.  KWS  manipulation  of  attachment  links. 


Automatic  Document  Attachment 

The  capability  to  enable  Do  Its  to  automatically  attach  documents  created  as  a  result 
of  their  execution  has  been  developed.  Because  of  the  complexity  of  “Do  It”  develop¬ 
ment,  this  capability  is  not  a  user-accessible  attachment  management  function  within 
KWS,  but  is  available  to  “Do  It”  developers.  Essentially,  this  capability  allows  “Do  It” 
developers  to  create  the  attachment  link  by  adding  an  attachment  record  to  the  KWS 
data  base  with  the  appropriate  Profile  information  assigned. 
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5  Integrating  KWS  With  External  Document 
Management  Systems 


The  DMS  review  discussed  in  Chapter  3  clearly  shows  that  technology  exists  for 
meeting  most  of  the  document  management  needs  of  KWS.  These  systems  provide 
state-of-the-art  document  management  capabilities  that  have  been  the  result  of  many 
years  of  research  and  development.  The  second  step  of  the  KWS  document  manage¬ 
ment  strategy  is  to  investigate  how  KWS  could  incorporate  these  existing  technologies. 

This  research  has  dealt  with  determining  whether  the  existing  DMSs  support 
integration  with  external  applications  and,  if  so,  developing  a  mechanism  for 
integrating  KWS  with  an  external  DMS.  A  literature  review  was  conducted  to  identify 
potential  DMSs  for  integration  with  KWS.  The  systems  identified  were  then  evaluated 
to  determine  if  they  could  provide  the  capabilities  required  by  KWS  and  a  system  was 
selected  for  integration.  An  external  interface  capability  in  KWS  was  required  to  be 
able  to  integrate  the  selected  system  with  KWS.  A  mechanism  for  providing  this 
interface  was  developed  and  the  selected  system  was  integrated  with  KWS. 


The  KWS  DMS  Integration  Architecture 

One  requirement  in  developing  the  KWS  DMS  integration  was  that  it  appear 
transparent  to  the  user.  Consequently,  the  interface  should  provide  users  with  state- 
of-the-art  document  management  via  the  external  application,  but  appear  as  if  it  were 
provided  by  KWS.  The  mechanism  chosen  to  support  this  requirement  was  the 
development  of  a  client/server  relationship  between  KWS  and  the  DMS. 

A  client/server  relationship  is  an  architecture  where  the  local  workstation  (the  client) 
requests  services  from  a  supplying  machine  (the  server)  such  as  a  LAN  File  Server. 
The  client  provides  the  user  interface  while  the  server  responds  to  data  requests  from 
the  client.  The  services  provided  by  the  server  depend  on  the  application  environment, 
but  are  typically  centered  around  multi-user  data  base  access.  This  multi-user  access 
is  an  essential  role  of  the  server,  meaning  that  the  server  is  used  for  more  than  just 
a  remote  file  server.  The  server  is  responsible  for  all  data  manipulation,  and  for 
passing  only  the  answer  back  to  the  client. 
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The  KWS  DMS  client/server  relationship  was  defined  with  KWS  acting  as  the  client 
and  the  DMS  as  the  server.  All  KWS  attachment  management  fimctions  were 
provided  by  making  requests  from  KWS  to  the  DMS.  This  architecture  provided  KWS 
users  with  transparent  access  to  the  capabilities  of  the  DMS,  thereby  meeting  the 
integration  requirements. 


Selecting  a  DMS  for  Integration  With  KWS 

To  be  considered  for  integration  with  KWS,  the  DMS  had  to  meet  three  criteria: 

1.  The  DMS  must  support  the  required  client/server  architecture  described  in  the 
previous  section. 

2.  The  DMS  must  offer  a  capability  for  integrating  with  the  KWS  application. 

3.  The  DMS  must  be  reasonably  priced  so  that  a  KWS/DMS  integration  could  be  an 
affordable  product  for  implementation  at  user  sites. 

The  three  products  that  met  these  criteria  were  PC  DOCS  Open,  SoftSolutions,  and 
Saros  Corporation’s  Mezzanine.  All  of  the  three  products  meeting  the  criteria  were 
good  candidates  for  the  KWS/DMS  integration.  SoftSolutions  was  selected  because  it 
seemed  to  provide  the  best  capability  for  integrating  with  the  KWS  application 
through  the  SoftSolution’s  “Software  Developer’s  Kit”  (SDK).  This  SDK  enables 
application  developers  to  write  software  routines  to  access  the  SoftSolutions*  DMS  data 
base.  This  capability  also  supports  the  required  clienb'server  architecture. 

The  selected  system  was  not  required  to  provide  the  “best”  set  of  user  capabilities. 
This  was  not  a  criterion  since  the  objective  of  this  research  was  to  investigate  the 
feasibility  of  integrating  KWS  with  commercially  available  DMSs,  not  to  identify  a 
single  integration  to  meet  all  user  requirements.  In  addition,  because  of  the  rapidly 
evolving  nature  of  DMS  products  at  the  time  of  this  research,  it  would  have  been 
difficult  to  identify  the  criteria  required  to  establish  the  “best”  set  of  user  capabilities. 
Even  if  this  had  been  a  requirement,  the  three  packages  investigated  were  foimd  to 
offer  essentially  the  same  capabilities. 


The  Integration  Process 

The  integration  process  consisted  of  three  parts: 

1.  Establishing  a  method  by  which  KWS  can  communicate  with  the  DMS  to  request 


services 
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2.  Disabling  the  DM  functions  internal  to  KWS  and  replacing  them  with  requests 
to  the  DMS 

3,  Establishing  a  method  for  maintaining  integrity  of  shared  data. 

For  KWS  to  communicate  with  the  DMS,  a  mechanism  within  KWS  is  required  by 
which  lews  can  call  the  DMS  functions.  In  addition,  the  DMS  must  provide  a 
mechanism  to  allow  these  function  calls.  SoftSolutions  provided  this  capability 
through  its  SDK.  The  KWS  source  code  was  modified  to  use  the  SDK  to  enable  the 
required  communication  between  the  applications. 

Since  this  integration  will  result  in  DMS  functions  being  provided  by  SoftSolutions, 
the  existing  document  management  capabilities  within  KWS  were  disabled.  At  the 
time  of  this  research,  there  was  no  established  way  to  disable  or  replace  these 
functions  in  KWS.  Modifications  were  made  directly  to  the  KWS  source  code  to  permit 
a  rerouting  of  this  functionality.  Additional  modifications  were  made  to  the  KWS 
interface  to  change  the  way  KWS  displayed  attachment  information. 

The  process  of  maintaining  integrity  of  shared  data  between  applications  is  called  data 
synchronization.  Because  KWS  is  using  the  DMS  to  manage  attachments,  the  two 
applications  need  to  agree  on  common  keys  to  reference  attachment  records  and  to 
maintain  some  data  about  attachments.  This  common  (shared)  data  must  at  all  times 
be  synchronized  so  that  each  application  “knows”  the  same  facts  about  an  attachment. 

For  this  integration,  not  all  information  about  an  attachment  needed  to  be  stored  in 
both  applications.  At  a  minimum,  it  is  reqviired  that  KWS  needs  to  store  information 
on  the  reference  for  each  attachment  in  the  DMS.  This  information  can  then  be  used 
by  KWS  to  request  the  document  from  the  DMS.  For  performance  reasons,  it  is 
recommended  that  any  document  information  stored  in  the  DMS  that  is  to  be 
displayed  in  the  KWS  interface,  should  also  be  stored  within  KWS.  This  includes  basic 
information  about  the  document  such  as  access  rights,  author,  title,  and  version 
number.  It  was  not  necessary  in  this  integration  to  store  any  additional  information 
fi*om  KWS  in  the  DMS  data  base. 

The  additional  requirement  of  KWS  to  manage  attachment  links  may  appear  to  add 
a  layer  of  complexity  to  data  synchronization  in  the  KWS  DMS  integration.  However, 
attachment  link  management  does  not  affect  this  integration.  In  the  existing  KWS 
architecture,  functions  for  managing  and  tracking  attachment  links  are  already 
provided.  Any  retrieval  of  information  related  to  attachment  links  can  already  be 
provided  through  queries  to  the  KWS  data  base.  These  queries  would  provide  the 
information  required  to  request  the  document  from  the  DMS.  Retrieval  of  the  actual 
documents  would  be  performed  through  requests  to  the  DMS. 
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The  Integration  Environment 

KWS  is  written  in  C  and  compiled  using  the  Microsoft  Visual  C++  programming 
environment.  The  integration  to  SoftSolutions  was  accomplished  by  making 
modifications  directly  to  the  KWS  attachment  module  using  the  SoftSolutions  SDK 
The  SoftSolutions  SDK  includes  two  integration  libraries — ^the  application  program¬ 
mers  interface  (API)  and  the  integrations  DLL.  Functions  from  both  of  these  libraries 
were  used  to  complete  this  project.  The  SoftSolutions  SDK  is  a  C-based  interface 
available  for  both  DOS  and  Windows  environments. 

The  integration  of  KWS  and  SoftSolutions  required  changing  the  fimctions  of  the  KWS 
attachment  menu  options  to  invoke  the  services  of  the  DMS  instead  of  the  built-in 
functions  already  provided  by  KWS,  which  retained  the  functions  required  to  display 
the  attachment  profile  and  create,  delete,  and  modify  attachment  links.  All  document- 
related  fimctions  were  replaced  with  SoftSolutions’  functions.  These  included 
attachment  editing,  versioning,  viewing,  storage  management,  and  security  and  access 
restrictions  that  had  previously  been  performed  by  KWS.  Only  a  portion  of  the 
dociunent  management  functions  available  in  SoftSolutions  were  made  accessible  via 
the  KWS  interface.  Some  functions,  such  as  full  text  searching,  were  not  included  in 
this  integration,  but  could  be  made  available  in  future  revisions. 

Four  new  fields  were  added  to  the  attachment  data  base  record  in  KWS:  (1)  The 
SoftSolutions  document  number,  (2)  the  version  number,  (3)  the  security  group  code, 
and  (4)  the  application  name.  These  modifications  to  the  KWS  attachment  table 
represent  the  minimum  data  base  restructuring  needed  to  complete  this  project. 
Additional  fields  could  be  added  to  display  more  information  about  the  attachment  to 
the  user. 

The  KWS  Attachment  options  are  the  same  as  those  provided  in  KWS  Version  2.0. 
The  following  sections  describe  how  these  options  are  impacted  by  the  integration  with 
SoftSolutions. 

Insert 

To  insert  an  attachment,  KWS  displays  an  attachment  profile  dialog  box  prompting 
the  user  for  information  about  the  attachment.  Within  the  attachment  profile,  the 
user  can  specify  the  attachment  title,  the  application  used  to  create/edit  the 
attachment,  the  security  group  code,  the  author  (not  necessarily  the  same  as  the 
creator),  and  the  document  type.  Other  profile  options  are  managed  by  SoftSolutions 
and  will  be  discussed  later. 
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Once  the  profile  has  been  completed,  the  user  is  given  the  option  of  importing  an 
existing  document  as  the  new  attachment  or  creating  a  new  document.  If  the  Import 
option  is  chosen,  the  user  is  asked  to  specify  the  DOS  filename  of  the  document  being 
imported.  The  user  is  next  given  the  option  of  editing  the  new  attachment.  If  this 
option  is  chosen,  the  attachment’s  application  is  laimched  and  the  attachment  file  is 
loaded  for  editing.  If  the  Create  option  is  chosen,  the  new  attachment’s  application  is 
laimched  with  an  empty  file  ready  for  editing.  In  either  case,  SoftSolutions  generates 
a  Document  Number  for  the  new  attachment  and  stores  it  in  the  appropriate  location. 
Also,  after  files  are  added  to  SoftSolutions,  an  indexer  window  appears  briefly  as 
SoftSolutions  adds  the  profile  information  to  its  index  tables. 

Delete 

Choosing  this  function  will  cause  the  selected  attachment(s),  and  all  of  their  versions, 
to  be  deleted  from  SoftSolutions.  The  appropriate  profile  information  is  then  removed 
from  the  SoftSolutions  index  tables.  The  user  is  asked  by  SoftSolutions  to  verify  the 
decision  to  delete  before  the  deletion  occurs.  KWS  is  then  responsible  for  deleting 
attachment  link  information  to  the  deleted  document  from  the  KWS  data  base. 

View/Print 

The  SoftSolutions  4.0  Document  Suite  comes  with  a  file  previewer  that  works  with 
most  types  of  file  formats.  The  previewer  is  defined  for  each  application  and  is 
specified  in  the  SoftSolutions  application  setup  screen.  Any  previewer  can  be  used,  but 
the  SoftSolutions'  previewer  is  specified  by  default.  Most  file  previewers  provide  the 
ability  to  print  and  view  documents.  The  SoftSolutions  file  previewer  provides  viewer 
and  printer  support  for  most  text,  spreadsheet,  bitmap,  drawing,  and  data  base  file 
formats. 

The  SoftSolutions  file  previewer  is  a  separate  executable  program  that  is  launched  by 
SoftSolutions.  Only  the  latest  version  of  the  document  can  be  previewed.  Earlier 
versions  must  be  accessed  via  the  Edit  option. 

Get  Copy 

This  options  allows  the  user  to  save  a  copy  of  the  attachment  file  to  a  specified 
location.  The  user  must  have  security  rights  to  at  least  view  the  document  to  use  this 
function.  If  more  than  one  version  of  the  document  exists,  the  user  is  prompted  to 
specify  the  desired  version. 
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Profile 

The  profile  option  allows  the  user  to  view  and  modify  profile  information.  If  the  user 
has  "edit”  access  to  the  attachment,  then  any  of  the  information  specified  in  creating 
the  attachment  can  be  modified.  All  other  users  are  able  to  view  the  profile 
information  (even  if  the  profile  is  private),  but  cannot  make  any  modifications. 

As  stated  previously,  the  KWS  interface  provides  the  Attachment  Profile  display. 
However,  information  is  stored  in  the  SoftSolutions'  data  base  that  is  not  contained  in 
the  KWS  data  base.  The  user  can  access  this  information  from  within  KWS  through 
em  “Additional  Information”  option  on  the  KWS  Attachment  Profile  display.  Selecting 
this  option  result  in  the  display  of  a  SoftSolutions*  screen  that  contains  an  activity  list 
showing  all  operations  that  have  been  performed  on  any  versions  of  the  specified 
attachment.  The  activities  list  is  ordered  by  date,  the  most  recent  operation  appearing 
first  in  the  list.  Users  with  “view/copy”  and  “edit”  access  to  the  attachment  will  be  able 
to  access  this  screen;  however,  all  other  users  will  be  limited  to  viewing  only  the  profile 
dialog  box. 

Edit 

The  ability  to  edit  an  attachment  is  available  only  to  those  users  that  have  “edit” 
access  to  the  specified  attachment.  When  an  edit  function  is  invoked,  a  call  is  made 
to  SoftSolutions  to  execute  the  application  specified  in  the  attachment  profile  and  to 
pass  the  filename  associated  with  the  chosen  attachment  to  this  application.  When 
editing  has  been  completed  and  the  application  has  been  closed  by  the  user,  control 
returns  to  KWS.  If  the  attachment  being  edited  has  more  than  one  version,  the  user 
is  asked  to  specify  the  version  to  be  opened. 

SoftSolutions  will  d3mamically  map  and  un-map  network  drives  if  necessary  to  provide 
access  to  the  selected  document.  The  system  administrator  is  responsible  for 
specifying  the  appropriate  mapping  parameters  during  SoftSolutions  installation. 

Version 

This  option  is  only  available  to  users  with  “edit”  access  to  the  specified  attachment. 
When  this  option  is  chosen  by  an  authorized  user,  the  SoftSolutions  version  screen  is 
displayed.  When  versions  are  added  to  existing  documents,  a  comment  can  be  entered 
for  each  version.  The  user  has  the  option  to  view  the  existing  version  comments  or 
create  a  new  version.  When  a  new  version  is  created,  the  profile  information  is 
re-indexed  and  the  version  count  is  incremented  by  one. 
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Security 

Security  for  attachments  is  provided  entirely  by  SoftSolutions.  The  server  software 
comes  with  three  predefined  security  classes:  public,  semi-private,  and  private.  Public 
access  has  no  restrictions.  Private  access  will  allow  viewing  of  the  profile  dialog  box 
only.  Semi-private  access  will  not  allow  any  “edit”  access  but  does  allow  the 
attachment  to  be  copied,  previewed,  and  printed.  Additional  security  groups  can  be 
defined  by  the  system  administrator. 

Document  security  can  be  used  to  control  the  storage  location  of  documents  in 
SoftSolutions.  Thus,  a  system  administrator  could  declare  that  all  private  docvunents 
be  stored  on  the  user’s  local  drive  (if  one  exists).  Sensitive  material  can  be  forced  onto 
removable  media  as  well  using  this  capability.  Each  individual  user’s  environment  can 
be  customized  so  that  “sensitive”  material  is  stored  in  an  appropriate  location. 


Lessons  Learned 

Additional  effort  is  required  to  develop  this  integration  into  a  fieldable  product. 
However,  this  prototype  integration  demonstrated  the  feasibility  of  integrating  KWS 
with  a  commercially  available  DMS.  The  lessons  learned  while  completing  this 
integration  can  be  used  to  “fine  tune”  the  integration  process. 

First  of  all,  the  KWS  code  needs  to  be  modified  to  simphfy  the  integration  process.  For 
this  prototype,  the  KWS  source  code  had  to  be  extensively  modified  to  disable  the 
existing  DMS  functions.  To  simplify  integration,  the  KWS  source  code  needs  to  be 
modified  to  separate  attachment  link  routines  from  document  management  routines. 
Essentially,  this  separation  was  demonstrated  by  this  integration,  but  further 
refinement  is  required  before  modifications  should  be  made  to  the  working  version  of 
KWS.  This  separation  would  also  enable  the  integration  of  KWS  with  any  system 
providing  DMS  services.  This  includes  the  basic  DMS  services  provided  by  KWS  (as 
described  in  Chapter  4)  or  those  provided  by  commercially  available  systems. 

Better  tools  are  required  for  developing  the  routines  necessary  to  communicate 
between  the  KWS  attachment  link  routines  and  the  DMS  routines.  This  function  was 
provided  by  the  SoftSolutions'  SDK  for  the  prototype  integration.  However,  at  the 
time  of  this  research,  the  SoftSolution’s  SDK  was  not  well  documented,  metking  the 
integration  process  more  difficult  than  it  should  have  been.  A  standard  set  of  tools  is 
required  to  initiate  requests  to  any  DMS.  These  standards  would  eliminate  the  need 
to  deal  with  integrating  KWS  with  multiple  DMSs.  Since  this  initial  integration,  eui 
Open  Document  Management  API  has  been  developed  to  provide  a  standardized,  high- 


USACERLAPP  95/38 


35 


level  interface  between  applications  and  DMSs.  The  use  of  this  ODMA  API  should  be 
investigated  for  providing  the  capabilities  required  for  further  KWS/DMS  integration 
efforts. 

The  DMS  capabilities  provided  through  a  KWS/DMS  integration  are  limited  only  by 
the  existing  capabilities  of  commercial  software.  The  time  and  cost  of  providing  these 
capabilities  via  the  integration  was  significantly  lower  than  that  of  modifying  KWS 
code  to  include  them.  In  addition,  integrating  KWS  with  a  commercial  DMS  also 
supports  the  Department  of  Defense,  Directorate  of  Defense  Information  Management, 
Corporate  Information  Management  (CIM)  Initiative  for  use  of  OfF-the-Shelf  software, 
which  requires  DOD  organizations  to  use  existing  commercial  software  when  possible 
instead  of  developing  software  in  house. 
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6  Advanced  Document  Management  in  KWS 


In  addition  to  the  basic  requirements  for  accessing  information  resources,  knowledge 
workers  require  capabilities  to  enhance  information  utilization.  Information 
utilization  is  the  actual  process  conducted  by  knowledge  workers  to  generate  a  product 
from  the  information  resources  they  access.  Advanced  document  management  in  KWS 
involves  the  integration  of  a  wide  range  of  technologies  to  not  only  store,  retrieve, 
track,  and  administer  documents,  but  also  to  promote  electronic  document  sharing, 
distribution,  review,  and  creation  through  collaboration  among  workgroups.  By 
providing  advanced  features  to  enhance  information  utilization  within  KWS,  the 
quality  of  knowledge  worker  products  can  be  improved. 

Activities  that  involve  knowledge  worker  information  utilization  were  analyzed  to 
determine  the  capabilities  required  by  knowledge  workers.  Next,  potentied  mecha¬ 
nisms  for  supporting  these  capabilities  through  modification  to  KWS  or  integration 
with  existing  and/or  emerging  technologies  were  identified.  The  following  sections 
describe  these  requirements  and  supporting  mechanisms. 


Support  for  Workgroup  Information  Manipulation 

Knowledge  worker  information  manipulation  is  often  a  workgroup  activity  requiring 
the  support  of  several  technologies.  For  example,  one  knowledge  worker  may  gather 
the  data  for  a  task  while  another  is  responsible  for  generating  a  report  from  the 
analysis  of  the  data.  Once  the  report  is  generated,  that  knowledge  worker  may 
distribute  the  report  to  several  knowledge  workers  who  must  review  it  and  provide 
feedback.  After  incorporating  review  comments,  the  report  could  then  be  routed  back 
to  the  review  group  for  final  approval  and  then  be  distributed  electronically 
throughout  the  organization.  To  support  this  process,  KWS  users  require  several 
advanced  document  management  capabilities.  These  include  the  capability  to: 
(1)  pass  completed  attachments  to  the  next  KWS  task  in  the  process,  (2)  allow  several 
knowledge  workers  to  author  and  review  a  document  at  the  same  time,  and 
(3)  electronically  distribute  docmnents  to  the  appropriate  members  of  the  organization. 
These  capabilities  could  be  provided  through  technologies  supporting  workflow,  group 
authoring  and  document  review,  and  electronic  document  distribution. 
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Workflow 

Workflow  is  a  capability  that  allows  an  organization  to  create  and  monitor  the  flow  of 
documents  from  one  place  to  another.  Commercially  available  systems  can  provide 
automated  workflow  to  track  each  document  throughout  the  system.  These  systems 
track  documents  based  on  a  predefined  set  of  linked  transactions  that  governs  the 
document’s  route  from  person  to  person  in  the  organization.  As  each  person  completes 
an  assigned  action  on  the  docwnent,  the  document  is  passed  to  the  next  person  in  the 
workflow.  Insurance  claim  processing  is  a  classic  example  of  a  workflow  application. 
There  is  a  predefined  set  of  actions  that  occur  on  the  insurance  claim  document  from 
its  point  of  receipt  in  the  claims  office  to  the  time  it  is  processed  and  the  final  action 
is  taken  on  the  claim.  This  type  of  process,  one  that  is  easily  defined  as  a  step-by-step 
set  of  actions,  can  be  readily  supported  by  commercial  workflow  applications. 

KWS  differs  fi'om  workflow  systems  in  that  it  is  “task”  instead  of  “document”  centered. 
Instead  of  routing  documents  within  a  workgroup,  KWS  schedules  tasks  with  attached 
documents.  Unlike  workflow  appUcations,  KWS  is  concerned  with  the  status  of  a  task, 
not  a  document.  (Where  a  document  is  the  end  product  of  a  task,  completion  of  the 
task  would  indicate  completion  of  the  document.)  In  addition,  KWS  differs  from 
workflow  s5rstems  in  its  assumption  that  most  knowledge  worker  tasks  are  not  easily 
defined  in  a  step-by-step  fashion.  Therefore,  the  workflow  paradigm  would  impose  an 
inappropriate  definition  structure  on  knowledge  worker  business  process  models. 
However,  some  knowledge  worker  teisks  can  be  defined  in  a  step-by-step  fashion  and 
KWS  should  support  such  a  structure. 

KWS  requires  additional  features  to  provide  the  capability  to  define  portions  of  a  task 
hierarchy  step  by  step.  This  capability  would  allow  knowledge  workers  to  automati¬ 
cally  pass  attached  documents  to  the  next  task  on  indicating  the  completion  of  a  task. 
Preliminary  functionality  to  support  work  flow  will  be  provided  in  the  next  KWS 
version  through  modifications  to  the  KWS  data  base  and  task  status  routines.  KWS 
already  provides  the  capability  to  define  tasks  in  sequential  order  via  the  predecessor, 
successor  functions.  An  additional  attribute  will  be  included  in  the  attachment  profile 
to  indicate  whether  the  attachment  is  an  end  product  of  the  task  being  performed. 
When  the  task  is  marked  as  completed,  the  KWS  task  management  routines  will 
determine  if  the  task  had  a  successor  and  if  so,  its  associated  end  products  will  be 
linked  to  the  successor.  Additionally,  a  “ready  to  start”  status  value  will  be  included 
in  the  task  status  attribute  to  indicate  to  the  user  that  a  successor  task  can  be  started 
once  the  task’s  predecessor  was  completed.  For  example,  if  the  task  “Write  Technical 
Report”  with  the  end  product  “Technical  Report”  is  marked  as  complete  within  KWS, 


♦ 

KWS  currently  supports  task  status  values  of  “Not  Started,”  “Started,”  “Finished,”  and  “Overcome  by  Events." 
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its  successor  task  “Review  Technical  Report”  will  be  given  the  status  “Ready  to  Start” 
and  the  dociiment  containing  the  technical  report  will  be  automatically  attached  to  it. 
In  the  enterprise-wide  case  where  the  successor  task  was  assigned  to  a  KWS  user  at 
another  location,  KWS  will  also  manage  the  process  of  moving  the  attachment  to  the 
file  server  at  the  appropriate  location  so  it  will  be  available  when  needed. 

Group  Authoring  and  Document  Review 

Knowledge  workers  require  the  capability  to  simultaneously  edit  and  review 
documents.  Workgroup  conferencing  software  is  being  investigated  as  a  potential 
technology  that  could  be  used  within  KWS  to  support  this  requirement.  This  emerging 
technology  provides  a  platform  for  group  discussion  and  decisionmaking.  It  enables 
information  to  be  simultaneously  transmitted  to  multiple  personal  computers  via  a 
LAN  or  modem  connections  where  it  can  be  discussed  and  modified.  This  allows  the 
capability  for  conducting  virtual  meetings  that  do  not  require  the  attendees  to 
physically  reside  at  the  meeting  location.  Also  called  “whiteboard  software,”  this 
technology  allows  one  or  more  users  to  simultaneously  annotate  graphics  files  and 
scanned  images.  These  annotations  are  useful  for  the  knowledge  worker  responsible 
for  incorporating  reviewer  notes  into’  the  revised  document.  In  addition,  this  software 
supports  application  sharing,  which  enables  participants  to  run  third-party  software 
at  the  same  time.  This  capability  could  be  used  to  enable  group  authoring  of 
documents  by  knowledge  workers  at  a  single  location  or  multiple  sites. 

Electronic  Document  Distribution 

Knowledge  workers  frequently  need  to  disseminate  information  generated  by  the 
execution  of  a  task  to  non-KWS  users.  This  dissemination  is  commonly  done  by 
printing  a  hard  copy  of  the  document  and  routing  it  to  the  appropriate  individuals. 
Features  could  be  provided  in  KWS  that  would  enable  users  to  select  a  mechanism 
such  as  electronic  mail  or  FAX  to  automatically  distribute  an  attached  document  to  the 
appropriate  individuals. 


Access  to  Enterprise  Information  Resources 

Information  utilization  is  often  supported  by  referential  documents  defining 
procedures,  regulations,  and  so  on  required  to  execute  a  task.  Knowledge  workers 
typically  need  access  to  a  core  set  of  referential  documents  relevant  to  the  specific 
missions  of  their  individual  organization.  In  KWS,  this  set  is  established  as  the 
process  model  is  developed.  It  is  not  likely  that  every  possible  association  between 
each  task  and  the  relevant  reference  would  be  established  within  KWS.  This  is 
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because  of  the  dynamic  nature  of  the  KWS  process  models.  KWS  models  are 
continually  changing  as  new  tasks  are  added  to  the  model  and  there  is  a  continual 
requirement  to  identify  new  associations.  Because  of  this,  knowledge  workers  require 
ad  hoc  access  to  these  references  from  anywhere  in  a  task  hierarchy  to  assist  in 
identifying  new  associations  to  support  task  execution.  Also,  it  is  not  always  necessary 
to  create  an  attachment  link  to  a  reference  each  time  it  is  accessed.  Therefore, 
knowledge  workers  require  the  flexibility  to  review  references  on  an  as-needed  basis 
without  having  to  create  an  attachment  link. 

Reference  Document  Library 

Enterprise  reference  documents  used  within  KWS  should  be  organized  in  a  central 
location.  By  accumulating  all  such  documents  in  this  central  location,  a  reference 
document  library  would  be  established  for  the  organization.  This  structure  would 
ensure  that  KWS  users  know  where  to  locate  reference  documents  and  that  the 
documents  could  be  accessed  by  anyone  in  the  organization.  In  addition,  this  structure 
would  reduce  inefficiencies  caused  by  storing  multiple  copies  of  the  same  document. 
These  inefficiencies  include  increased  requirements  for  storage  capacity  and  additional 
efforts  required  to  manage  document  updates.  For  example,  if  two  KWS  tosks  require 
access  to  the  same  reference  document,  a  link  from  each  task  should  be  established  to 
the  one  copy  of  the  document.  Without  access  to  a  library  of  resources  to  select  from, 
KWS  users  may  be  unaware  that  a  document  is  already  stored  in  the  KWS  environ¬ 
ment.  Thus,  it  is  very  likely  that  two  copies  of  the  document  would  be  imported  into 
KWS  with  each  task  linked  to  a  different  copy. 

Modifications  to  the  existing  document  management  routines  and  centralized  file 
storage  structure  of  KWS  could  support  creation  of  an  organization’s  reference 
document  library.  Additional  attributes  could  be  included  in  the  attachment  profile 
to  indicate  that  a  document  is  a  reference  and  to  list  the  contexts  in  which  it  is  used. 
For  example,  a  document  defining  the  development  of  a  Government  contract  could  be 
defined  as  a  reference  for  the  context  “Contract  Development.”  Additional  document 
management  search  routines  could  then  be  developed  to  provide  KWS  users  assistemce 
in  locating  references  in  the  library. 

Task  Inheritance  of  Referential  Document  Attachment  Links 

Many  attachment  links  from  tasks  to  references  in  KWS  may  actually  be  relevant  for 
multiple  if  not  all  tasks  in  a  particular  hierarchy.  It  is  possible  to  create  multiple  links 
to  the  reference  document  from  each  task  in  the  hierarchy,  but  this  would  be 
unnecessarily  complicated.  Instead,  a  mechanism  could  be  provided  within  KWS  to 
enable  a  child  task  to  inherit  attachment  links  from  its  parent  task.  Rather  than 
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manually  creating  a  link  between  each  task  and  the  reference  document,  one  link  could 
be  created  at  the  appropriate  level  of  the  hierarchy  and  all  sublevel  tasks  would 
automatically  be  associated  with  the  document. 


Document  Search  and  Retrieval 

Even  when  knowledge  workers  are  provided  with  quick  access  to  the  set  of  information 
resources  relevant  for  their  tasks,  it  may  not  be  enough  for  them  to  simply  retrieve  the 
references.  Instead,  they  may  need  assistance  in  identifying  a  subset  of  available 
references,  viewing  a  specific  section  of  a  reference,  or  viewing  all  relevant  sections  of 
a  reference.  For  example,  a  KWS  process  “Generate  Government  Contract”  would 
have  several  tasks  in  the  process  hierarchy  that  reqviire  associations  with  Government 
contracting  regulations.  Depending  on  the  requirements  of  the  specific  contract,  only 
a  subset  of  these  references  may  be  required  by  specific  task.  From  this  subset,  a  task 
may  always  require  an  association  with  a  particular  paragraph  within  a  reference 
while  another  task  may  require  the  capability  to  access  specific  portions  of  the 
regulation  based  on  the  requirements  of  the  particular  contract  (e.g.,  all  portions 
related  to  Automated  Data  Processing  [ADP]  services). 

Full  Text  Query 

The  requirements  for  accessing  a  subset  or  portions  of  all  relevant  documents  could  be 
provided  through  full  text  query  capabilities.  Full  text  query  is  a  technology  that 
allows  searching  for  a  specific  word  or  phrase  within  a  document  or  set  of  documents. 
In  the  previous  example,  a  knowledge  worker  could  enter  the  phrase  “ADP”  and  a  list 
of  documents  containing  this  phrase  would  be  provided  to  the  user.  The  user  covild 
then  search  each  of  these  documents  individually  to  view  all  sections  containing  a 
reference  to  ADP. 

Bookmarks 

The  ability  to  link  a  task  to  a  specific  portion  of  a  document  could  be  achieved  through 
the  use  of  bookmarks.  Bookmarks  are  used  to  mark  a  location  in  a  document  so  that 
the  user  can  return  to  that  location  quickly.  Capabilities  for  placing  “electronic” 
bookmarks  in  a  document  are  provided  in  many  commercially  available  word¬ 
processing  and  spreadsheet  packages.  This  can  meet  knowledge  workers’  require¬ 
ments  for  bookmarking  within  documents  they  create.  In  addition,  bookmarking  is  a 
common  feature  available  in  electronic  publishing  software  used  to  create  and 
distribute  corporate  information  repositories. 
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Global  Access  to  External  Information  Resources 

In  addition  to  the  core  set  of  information  resources,  knowledge  workers  may  require 
access  to  a  variety  of  external  information  resources  from  an3rwhere  within  the  KWS 
task  hierarchy.  For  example,  the  World  Wide  Web  is  a  quickly  expanding  resource  of 
information  in  a  variety  of  subjects.  The  World  Wide  Web  was  created  as  a  way  to 
enable  physicists  to  collaborate  more  effectively  over  the  Internet.  It  has  since 
expanded  to  support  collaboration  aroimd  the  world  among  a  multitude  of  workgroups. 
As  the  World  Wide  Web  continues  to  grow,  the  benefits  to  knowledge  workers  for 
accessing  the  information  on  it  also  grows.  KWS  users  need  a  way  to  easily  access  and 
share  information  on  the  World  Wide  Web  with  members  of  their  workgroups  residing 
at  remote  sites  aroimd  the  world.  Access  to  other  external  information  resources  such 
as  online  library  catalogs,  documents  published  on  CD-ROM,  and  so  on  are  also 
required. 

World  Wide  Web  Access 

KWS  can  integrate  with  external  software  from  individual  tasks  via  “Do  Its,”  or 
globally  from  all  tasks  via  the  “Tools”  option.  Essentially,  the  “Tools”  option  allows  a 
user  to  launch  external  software  by  selecting  it  from  the  set  of  tools  listed.  Several 
commercially  software  packages  enable  users  to  easily  log  onto  the  Internet  and 
browse  through  its  information  resources  (e.g.,  Mosaic).  By  providing  access  to  these 
packages  via  the  tools  option,  KWS  can  provide  users  with  access  to  the  World  Wide 
Web  from  anywhere  within  the  KWS  task  hierarchy. 

Online  Document  Repositories  Access 

An  increasing  number  of  document  collections  are  becoming  available  on  electronic 
media  such  as  CD-ROM.  For  example,  “Computer  Select”  is  a  commercial  CD-ROM 
library  containing  articles  from  a  number  of  computer  trade  journals.  Through  the 
Computer  Select  interface,  a  user  can  identify  and  retrieve  relevant  documents  using 
fijll  text  query.  Access  to  Computer  Select  or  other  online  document  services  could  be 
provided  in  the  same  manner  as  World  Wide  Web  access  via  the  KWS  tools  option. 
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7  Summary  and  Recommendation 


Knowledge  workers  require  access  to  a  variely  of  information  resources  that  support 
their  business  processes.  KWS  provides  the  capability  for  knowledge  workers  to  define 
associations  between  a  task  and  the  information  resources  required  to  support 
execution  of  the  task.  These  associations,  called  attachments,  allow  knowledge 
workers  to  access  documents  while  executing  a  task.  Attachments  can  be  made  to  any 
electronically  stored  information  resource  from  anywhere  within  the  KWS  process 
model.  As  the  size  and  complexity  of  the  KWS  model  increases,  the  complexity  of 
managing  the  documents  involved  also  increases.  An  effective  mechanism  for 
managing  the  creation  and  use  of  attachments  is  required  to  ensure  that  the 
knowledge  worker  is  able  to  easily  access  their  required  information  resources. 

This  research:  (1)  developed  a  strategy  for  providing  KWS  users  with  improved 
attachment  management  capabilities  and  (2)  developed  methods  to  implement  this 
strategy  through  a  series  of  modifications  to  KWS.  This  was  done  through  a  three-step 
approach  that  provides  KWS  users  with  increasing  attachment  management  support: 

1.  Identifying  immediate  needs  of  KWS  users  to  improve  attachment  management. 

2.  Modifying  KWS  Version  1.7  to  support  these  needs. 

3.  Investigating  the  capability  to  provide  state-of-the-art  support  through 
integration  with  external  commercially  available  DMSs,  investigating  the 
advanced  needs  of  knowledge  workers  to  support  manipulation  of  information 
resources  after  retrieval,  and  identifying  potential  mechanisms  for  providing  the 
required  capabilities. 

This  research  contributed  to  the  development  of  improvements  subsequently 
incorporated  into  KWS  Version  2.0,  now  available  to  KWS  users.  This  study 
demonstrated  the  feasibility  of  providing  state-of-the-art  capabilities  via  integration 
of  KWS  with  a  commercially  available  DMS.  Also,  several  potential  mechanisms  were 
identified  for  meeting  the  advanced  needs  of  knowledge  workers  in  support  of 
information  manipulation. 

Continued  research  and  development  is  required  to  fully  implement  the  document 
management  capabilities  described  in  this  report.  The  following  activities  are 
recommended  to  achieve  this  end: 
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1.  Modify  the  existing  KWS  code  to  simplify  integration  with  external  software 
applications  to  support  document  management. 

2.  Complete  development  of  the  KWS  capability  for  integrating  with  external  DMSs 
through  ODMA  APIs. 

3.  Modify  the  KWS  code  to  support  the  identified  advanced  document  management 
features. 
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